Remarks 

Claims 1-29 are pending in the application. All claims stand rejected. By this 
paper, claims 1-4, 6-8, 10-16, 18-21, 23-25, and 27-29 have been amended. 
Reconsideration of all pending claims herein is respectfully requested. 

Claims 1, 8, 12, and 29 were rejected under 35 U.S.C. 102(e) as being 
anticipated by Lakshman et al. ("Lakshman"). Claims 2-7, 9-11, 13-17, and 27-28 
were rejected under 35 U.S.C. 103(a) as being unpatentable over Lakshman in view 
of Ito et al. ("Ito"). Claims 18, 21-22, and 26 were rejected under 35 U.S.C. 103(a) as 
being unpatentable over Lakshman in vie of Humpleman. Claims 19-20 and 23-25 
were rejected under 35 U.S.C. 103(a) as being unpatentable over Lakshman et al. in 
view of Humpleman and further in view of Ito. These rejections are respectfully 
traversed. 

Claim 1 has been amended merely to more particularly point out and distinctly 

claim what the applicant regards as his invention. As amended, claim 1 recites a 

method comprising: 

identifying a previously-generated histogram of bitrate as a function of 
time associated with a previously-encoded multimedia program to be 
transmitted to a multimedia node; and 

changing a bandwidth allocation for the multimedia node in anticipation 
of a future bitrate spike indicated in the bitrate histogram for said multimedia 
program . 

These claimed features allow a media server to anticipate a future bitrate 
spike in a previously-encoded multimedia program to be sent to a receiving node, 
and to proactively adjust the bandwidth allocated to the receiving node to handle the 
spike without interruption. By retrieving a previously-generated bitrate histogram for 



9 



the previously-encoded multimedia program, the server is aware of the spike well 
before it occurs, and may take steps to prevent a buffer underrun, such as by 
providing additional bandwidth to fill the receiving node's buffer. 

Lakshman relates to an entirely different "adaptive" encoding process based 
on bitrate prediction for video to be encoded in the future . For example, his encoder 
predicts (501) the need for rate allocation for future frames and provides (502) the 
predicated rate to a network. The network allocates (504) bandwidth in response to 
the request and advises (504) the source of an explicit rate based on the actual 
available bandwidth. The encoder at the source then adjusts (505) the current rate 
based on the advised explicit rate. See FIG. 5. 

By contrast, the claimed invention does not predict the bitrate. It conclusively 
knows the required bitrate at any point during the transmission based on the 
previously-generated bitrate histogram for the multimedia program. Moreover, the 
claimed invention does not adjust the encoding rate based feedback from the 
network. Indeed, the content has already been encoded and does not need to be re- 
encoded. 

The reason Lakshman needs to predict the bitrate and adjust the encoding is 
because Lakshman relates to video that has not yet been encoded, such as in a 
video conference. Col. 9, lines 64-67. Lakshman uses a "mechanism for predicting 
demands to be made of the network based on the character of the video information 
which is to be encoded in the future ." Col. 5, lines 2-4. The encoder cannot know in 
advance what the bitrate will be at any given time, since the video has not yet been 
captured, let alone encoded. Accordingly, as explained below, it can only look at the 
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character or type of video to be sent, making the goals and overall mechanism 
employed by Lakshman completely different from that of the claimed invention. 

Turning to the limitations of claim 1, Lakshman does not identify "a previously- 
generated histogram of bitrate as a function of time ." First, the graph referred to by 
the Examiner in FIG. 6A is not a histogram of "bitrate as a function of time," as 
claimed. Indeed, it is not even a histogram of bitrate. FIG. 6A shows "cells per 
frame" vs. "frequency." This tells next to nothing about the bitrate. All B-frames do 
not require the same amount of data. Moreover, this graph tells nothing about the 
ratio of B frames to I or P frames. Determining the bitrate would require substantially 
more data, which is not presented in the graph of FIG. 6A. 

Second, the graph of FIG. 6A cannot be a histogram of bitrate as a function of 
time, which could be used to anticipate upcoming bitrate spikes, because there is no 
"time" axis . For example, the graph shows approximately 1000 occurrences of 100 
cells per frame, with a much smaller number of occurrences of 250-300 cells per 
frame. However, this graph tells nothing about the temporal position within the media 
program at which the 250-300 cells per frame occur. How, then, can it be used to 
anticipate bitrate spikes? 

Furthermore, Lakshman does not disclose or suggest a histogram of bitrate as 
a function of time "associated with a previously-encoded media program to be 
transmitted to a multimedia node." Lakshman's histogram in FIG. 6A is a histogram 
of cell rates for a particular type of multimedia content (e.g., video conferencing), not 
a particular media program to be sent to a receiving node, as claimed. In other 
words, FIG. 6A is used to model the characteristics of a type of multimedia content, 
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not to map a specific media program's content. As explained by Lakshman, "[hjaving 
considered the active and inactive sources and their characteristics , it is possible to 
thus model and predict what the cell rate needs will be for the encoder based on the 
types of video to be transmitted." Lakshman simply does not disclose or suggest a 
previously-generated bitrate histogram for the media program to be transmitted . It is 
a generic histogram of cell rates vs. frequency for categories of multimedia. 

Finally, Lakshman does not "change a bandwidth allocation for the multimedia 
node in anticipation of a future bitrate spike indicated in the bitrate histogram for said 
multimedia program ," as required by claim 1. Even if Lakshman's "predictions" could 
be construed to be a previously-generated histogram (which is not disclosed or 
suggested by Lakshman), his encoder only predicts "needed rates over very short 
intervals." Col. 3, line 60. Lakshman does not predict the needed rates for an entire 
media program and subsequently store the predicted rates as a histogram, which can 
be later identified and used for changing bandwidth allocations for a receiving node, 
as claimed. 

The addition of Ito does not cure the deficiencies of Lakshman. Ito does not 
disclose bitrate histograms. Rather, Ito's video data index includes instructions for 
how to extract certain frames of video data to achieve one of several different bitrates 
depending on the network load. In other words, if the network load won't permit the 
transmission full 1.5 Mbps video data, Ito's server degrades the video quality, as 
instructed in the video data index, by selecting some frames and dropping others. 

For example, as shown in FIG. 3 of Ito, in order to reduce the bitrate to 768 
Kbps, the system transmits all of the "I" frames, but only three "P" frames for each 
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GOP (group of pictures), which degrades the video quality somewhat, but is 



preferable to a buffer underrun. Similarly, to achieve 128 Kbps, the system transmits 
only one T frame for every 5 GOPs, substantially degrading the video quality. 

As explained by Ito, the "video data index 13 indicates the [frame] types [/.e., I 
or P], numbers [i.e., three "P" frames per GOP], and time axis of data [/.e M the time 
index of the frames} which are to be selected from the compressed original video 
data by the video data assembler 14." Col. 6, lines 9-12. Ito is concerned with 
modifying the video data, and the video data index only tells how the video data is to 
be modified. It is not a histogram of bitrate requirements for the video data. 

This is clearly set forth in the following example described by Ito: 

For example, when video data are transferred at a transfer bit rate of 
1.5 Mbps, 64 Kbyte of data are delivered every 340 msec. If there is a 
margin of the load imposed on the network, the system can maintain 
the transfer bit rate of 1.5 Mbps for these delivery parameters. 
However, the video server cannot maintain the transfer bit rate if the 
load is increased. In order to resolve this problem, the video server 
starts to measure a time T r required for transfer of data at constant 
intervals Ti so as to determine the load imposed on the network just 
after transfers of video data are started. Then, the video server, in steps 
F43 and 45, compares a measured value T r to a reference value T d i, 
which is the maximum time required for transfer of data that cannot be 
exceeded in order to maintain the current transfer bit rate. 

If the measured value T r exceeds the reference value T d i, the video 
data assembler 14, in step F44, extracts all the I pictures and P 
pictures defined as video data to be transferred at the second transfer 
bit rate from the video data 12 so as to set the transfer bit rate to the 
second bit rate setting, modifies the header information in such a 
manner that the information shows that video data to be transferred are 
constructed of all the I and P pictures, and reassembles the extracted 
data to create video data to be transferred at the second transfer bit 
rate which is reduced from the original transfer bit rate by one level. 
The video data delivery unit 15 delivers the video data created at the 
new transfer bit rate while creating the video data rather than deliver all 
video data after they are created from the video data 12. 
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Col. 6, lines 29-56 (emphasis added). 

Nothing in FIG. 3 of Ito or the accompanying disclosure suggests the claimed 
histogram of bitrate data. Indeed, Ito does not require one. Ito merely reduces the 
bitrate when the current network load makes it impossible to transfer the video data 
at the full bitrate. Ito does not anticipate future bandwidth spikes , as in the claimed 
invention. Furthermore, Ito does not change bandwidth allocations. Rather, Ito 
keeps the same bandwidth allocations and modifies the underlying video data by 
removing frames. 

By contrast, a system in accordance with the present invention relies on a 
bitrate histogram to make proactive changes to bandwidth allocations, without 
modifying the underlying video data . A system in accordance with the present 
invention does not degrade the video data as in Ito, e.g., only passing three "P" 
frames per GOP. 

By anticipating upcoming bandwidth spikes using the bandwidth histogram, a 
system in accordance with the present invention may take proactive measures to 
increase bandwidth to a particular multimedia node to ensure that the node's buffer is 
full when the spike arrives. Ito has no such teaching or suggestion. 

A system in accordance with the present invention does not require a "network 
load sensor 17" as in Ito, or need to receive explicit (actual) rates from the network, 
as in Lakshman. According to the claimed invention, bandwidth changes are initiated 
in anticipation of the spike, well before a network load sensor may detect a problem. 
Ito's reliance on a network load sensor is a significant deficiency of his system, and 
actually teaches away from the claimed bitrate histogram. 
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The addition of Humpleman does not cure the deficiencies of Ito and 
Lakshman. Humpleman merely discloses a home network system that provides 
browser-based command and control. Nothing in Humpleman suggests the claimed 
bitrate histogram. Furthermore, nothing in Humpleman suggests modifying a 
bandwidth allocation in anticipation of a bitrate spike indicated within a bitrate 
histogram. 

Accordingly, the applicant respectfully submits that claim 1 is patentably 
distinct over the cited references. Claims 2-7 depend directly or indirectly from claim 
1 and are thus believed to be patentably distinct for at least the same reasons. 

Claim 2, as amended, recites the further step of "locating said bitrate 
histogram in a database of previously-generated bitrate histograms using multimedia 
content identification data." Even if Lakshman disclosed a histogram of bitrate as a 
function of time, which he does not, he does not disclose or suggest a database of 
bitrate histograms corresponding to different media programs. As explained above, 
Ito's indices are not bitrate histograms within any possible meaning of the term, and 
Humpleman does not disclose anything remotely similar to a bitrate histogram. 

As amended, claim 8 recites a method for providing efficient bandwidth 

allocation on a bandwidth-limited network comprising: 

receiving a request for a previously-encoded multimedia program from 
a first multimedia node; 

allocating a first amount of bandwidth to supply said multimedia 
program content to said multimedia node; and 

dynamically adjusting said first amount of bandwidth based on a 
previously-generated template of bitrate data as a function of time indicating 
changes in bitrate requirements of said multimedia program, wherein said 
adjusting is done prior to the occurrence of said changes. 

a r- 



As explained above, Lakshman does not disclose a histogram of bitrate " as a 
function of time ." Furthermore, Lakshman does not disclose a previously-generated 
histogram of bitrate as a function of time associated with a previously-encoded 
multimedia program. 

Likewise, Ito does not disclose or suggest a template of bitrate data " as a 
function of time " (e.g., a histogram). In addition, because of Ito's reliance on a 
network load sensor rather than a bitrate histogram, he does not make bandwidth 
changes prior to the occurrence of the changes in bitrate {i.e., the bitrate spike) . 
Indeed, Ito does not even manipulate bandwidth, as discussed above in connection 
with claim 1, but simply reassembles the video data, leaving out "P" and sometimes 
"I" frames. 

Claim 12 requires the further step of "dynamically adjusting said first amount 
of bandwidth based on a histogram of bitrate data indicating changes in bitrate 
requirements of a multimedia program requested by a second multimedia node." 
None of the references disclose changing a bandwidth allocation of a first multimedia 
node based on a bitrate histogram of a second multimedia node. Even if Lakshman's 
prediction could be construed to be a template of bitrate data with respect to time, 
which it cannot, Lakshman does not make bandwidth allocation changes based on 
"bitrate requirements of a multimedia program requested by a second multimedia 
node." Likewise, even if Ito's video data index could be construed to be a template of 
bitrate data as a function of tine, which it cannot, Ito could only make decisions 
concerning modifying the video data based on the index of multimedia content 
requested by the first multimedia node. 
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Accordingly, the applicant respectfully submits that claims 8 and 12 are 
patentably distinct over the cited references. Claims 9-17 depend directly or 
indirectly from claim 8 and are thus believed to be patentably distinct for at least the 
same reasons. Claims 18-29 have been amended to include similar limitations to 
those found in claims 1-17 and are likewise believed to be patentably distinct. 

In view of the foregoing, the applicant respectfully submits that claims 1-29, as 
amended, are patentably distinct over the cited references, alone or in combination. 
Early allowance of all pending claims herein is respectfully requested. 



STOEL RIVES LLP 

One Utah Center Suite 1 100 

201 S Main Street 

Salt Lake City, UT 841 1 1-4904 

Telephone: (801)328-3131 

Facsimile: (801)578-6999 



Respectfully submitted, 



Digeo, Inc. 



By 




